fix: handle SSE transport send errors after SSE disconnects - #1733
Conversation
…ontextprotocol#1014) When the SSE connection is closed (e.g. client disconnects during rapid reconnection), webAppTransport.send() rejects with "Not connected". The stderr handler was calling send() without awaiting or catching the returned promise, causing unhandled rejections that crash the server. Add .catch() to both send() call sites in the stderr data handler so that errors from a closed SSE connection are silently ignored instead of crashing the process. Also move the cleanup logic in the MODULE_NOT_FOUND branch into .finally() so transports are cleaned up regardless of whether the notification send succeeded.
|
Gentle maintainer follow-up: this PR remains mergeable, and the build and Playwright checks are green; GitHub currently shows it blocked only on required review. Is the SSE-disconnect error-handling direction acceptable, or is there a change you would like before review? |
|
Closing: v1 is deprecated. Thank you for this contribution, and apologies for the long wait for a response. v1 will receive security fixes only. We reviewed every open v1 PR for security impact before closing — see the backlog triage in #1819 — and a small number were retained for a final If the underlying problem still exists in v2, we'd genuinely like to know. Please open an issue describing it against v2. Note that we accept external contributions as issues rather than pull requests — maintainers handle design and implementation through a prompt-driven workflow. See Thanks again for taking the time to contribute to the Inspector. |
Summary
webAppTransport.send()promises in the stdio stderr handler.finally()for theMODULE_NOT_FOUNDpath so cleanup still runs if the SSE client already disconnectedNot connectedrejections when multiple SSE connections race and one closes before stderr forwarding completesTesting
npm cinpm run build-serverFixes #1014.
Supersedes the earlier stale attempt in #1129.